Summary:
The allocator interface is supposed to have 16 byte alignment (to keep
it consistent with the CPU allocator. We could probably drop this to 8
if desires.) But this was not enforced because the number of bytes used
for the bitfield sometimes resulted in alignment of 8 instead of 16.
Explicitly align the number of bytes to be a multiple of 16 even if
unused.

PR llvm#141106 changed the debuginfo metdata to allow dynamic bit offsets
and sizes. This caused a crash in lld when using LTO.

The problem is that lazyLoadOneMetadata assumes that the metadata in
question can be cast to MDNode; but in the typical case where the offset
is a constant, this is not true.

This patch changes this spot to allow non-MDNodes through.

The included test case comes from the report in llvm#141106.

…BB_ADDR_MAP_V0). (llvm#146186)

Version 2 was added more than two years ago
(llvm@6015a04).
So it should be safe to deprecate older versions.

This patch fixes:

  lldb/source/Plugins/ObjectFile/Mach-O/ObjectFileMachO.cpp:415:7:
  error: label at end of compound statement is a C++23 extension
  [-Werror,-Wc++23-extensions]

  lldb/source/Plugins/ObjectFile/Mach-O/ObjectFileMachO.cpp:536:7:
  error: label at end of compound statement is a C++23 extension
  [-Werror,-Wc++23-extensions]

  lldb/source/Plugins/ObjectFile/Mach-O/ObjectFileMachO.cpp:672:7:
  error: label at end of compound statement is a C++23 extension
  [-Werror,-Wc++23-extensions]

This patch introduces a new custom type `!spirv.arm.tensor<>` to the
MLIR SPIR-V dialect to represent
`OpTypeTensorARM` as defined in the `SPV_ARM_tensors` extension.

The type models a shaped tensor with element type and optional shape,
and implements the
`ShapedType` interface to enable reuse of MLIR's existing shape-aware
infrastructure.

The type supports serialization to and from SPIR-V binary as
`OpTypeTensorARM`, and emits the
required capability (`TensorsARM`) and extension (`SPV_ARM_tensors`)
declarations automatically.

This addition lays the foundation for supporting structured tensor
values natively in SPIR-V and
will enable future support for operations defined in the
`SPV_ARM_tensors` extension, such as
`OpTensorReadARM`, `OpTensorWriteARM`, and `OpTensorQuerySizeARM`.

Reference: KhronosGroup/SPIRV-Registry#342

---------

Signed-off-by: Davide Grohmann <[email protected]>
Signed-off-by: Mohammadreza Ameri Mahabadian <[email protected]>

…/isGuaranteedNotToBeUndefOrPoisonForTargetNode (llvm#146728)

None of these implicitly generate UNDEF/POISON

The only use of Receiver is to initialize RecExpr.  This patch renames
Receiver to RecExpr while removing the cast statement.

)

This patch fixes the following error:
```
llvm/lib/Support/TextEncoding.cpp:274:11: error: cannot initialize a variable of type 'char *' with an rvalue of type 'const char *'
  274 |     char *Input = InputLength ? const_cast<char *>(Source.data()) : "";
      |           ^       ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
```

In DXC, there is an option to enable all KHR extension. I would like to
extend the existing `-spirv-ext` backend commandline option to have the
same capability. It is like the special case for `all` execept it only
adds the `SPV_KHR_*` extensions.

Part of llvm#137650.

This reverts commit 988876c.
Was intended to be a PR

unbreak gcc CI bots.

Refactors new/delete interceptor macros per the discussion in llvm#145087.

Signed-off-by: Justin King <[email protected]>

…lvm#146909)

The only difference is that with libc++ the summary string contains the
derefernced pointer value. With libstdc++ we currently display the
pointer itself, which seems redundant. E.g.,
```
(std::unique_ptr<int>) iup = 0x55555556d2b0 {
  pointer = 0x000055555556d2b0
}
(std::unique_ptr<std::basic_string<char> >) sup = 0x55555556d2d0 {
  pointer = "foobar"
}
```

This patch moves the logic into a common helper that's shared between
the libc++ and libstdc++ formatters.

After this patch we can combine the libc++ and libstdc++ API tests (see
llvm#146740).

…ch64 macOS version

Currently failing on the arm64 macOS CI with:
```
06:59:37  Traceback (most recent call last):
06:59:37    File "/Users/ec2-user/jenkins/workspace/llvm.org/lldb-cmake-sanitized/llvm-project/lldb/test/API/commands/frame/var-dil/basics/GlobalVariableLookup/TestFrameVarDILGlobalVariableLookup.py", line 47, in test_frame_var
06:59:37      self.expect_var_path("ExtStruct::static_inline", value="16")
06:59:37    File "/Users/ec2-user/jenkins/workspace/llvm.org/lldb-cmake-sanitized/llvm-project/lldb/packages/Python/lldbsuite/test/lldbtest.py", line 2589, in expect_var_path
06:59:37      value_check.check_value(self, eval_result, str(eval_result))
06:59:37    File "/Users/ec2-user/jenkins/workspace/llvm.org/lldb-cmake-sanitized/llvm-project/lldb/packages/Python/lldbsuite/test/lldbtest.py", line 301, in check_value
06:59:37      test_base.assertSuccess(val.GetError())
06:59:37    File "/Users/ec2-user/jenkins/workspace/llvm.org/lldb-cmake-sanitized/llvm-project/lldb/packages/Python/lldbsuite/test/lldbtest.py", line 2597, in assertSuccess
06:59:37      self.fail(self._formatMessage(msg, "'{}' is not success".format(error)))
06:59:37  AssertionError: '<user expression 0>:1:1: use of undeclared identifier 'ExtStruct::static_inline'
06:59:37     1 | ExtStruct::static_inline
06:59:37       | ^' is not success
06:59:37  Config=arm64-/Users/ec2-user/jenkins/workspace/llvm.org/lldb-cmake-sanitized/lldb-build/bin/clang
06:59:37  ----------------------------------------------------------------------
06:59:37  Ran 1 test in 2.322s
06:59:37
```

Can't repro this locally so skipping on older macOS versions that the CI
is running.

The inheritance hierarchy for `llvm::ms_demangle::Node`
([doxygen](https://llvm.org/doxygen/structllvm_1_1ms__demangle_1_1Node.html))
is a bit more involved. One thing that's missing without RTTI is the
ability to determine if a node is a symbol, identifier, or type (or one
would need to check for every kind).

This PR adds support for `dyn_cast`, `isa`, and friends to
`llvm::ms_demangle::Node`. As the type already has a `kind()`, this
mainly adds `classof` to the nodes as well as some start and end markers
in the `NodeKind` enum.

…lvm#141937)

RFC on discourse:
https://discourse.llvm.org/t/rfc-debug-info-for-coroutine-suspension-locations-take-2/86606

With this commit, we add `DILabel` debug infos to the resume points of a
coroutine. Those labels can be used by debugging scripts to figure out
the exact line and column at which a coroutine was suspended by looking
up current `__coro_index` value inside the coroutines frame, and then
searching for the corresponding label inside the coroutine's resume
function.

The DWARF information generated for such a label looks like:

```
0x00000f71:     DW_TAG_label
                  DW_AT_name    ("__coro_resume_1")
                  DW_AT_decl_file       ("generator-example.cpp")
                  DW_AT_decl_line       (5)
                  DW_AT_decl_column     (3)
                  DW_AT_artificial      (true)
                  DW_AT_LLVM_coro_suspend_idx   (0x01)
                  DW_AT_low_pc  (0x00000000000019be)
```

The labels can be mapped to their corresponding `__coro_idx` values
either via their naming convention `__coro_resume_<N>` or using the new
`DW_AT_LLVM_coro_suspend_idx` attribute. In gdb, those line numebrs can
be looked up using `info line -function my_coroutine -label
__coro_resume_1`. LLDB unfortunately does not understand DW_TAG_label
debug information, yet.

Given this is an artificial compiler-generated label, I did apply the
DW_AT_artificial tag to it. The DWARFv5 standard only allows that tag on
type and variable definitions, but this is a natural extension and was
also blessed in the RFC on discourse.

Also, this commit adds `DW_AT_decl_column` to labels, not only for
coroutines but also for normal C and C++ labels. While not strictly
necessary, I am doing so now because it would be harder to do so later
without breaking the binary LLVM-IR format

Drive-by fixes: While reading the existing test cases to understand how
to write my own test case, I did a couple of small typo fixes and
comment improvements

This patch is part of a series that adds origin-tracking to the debugify
source location coverage checks, allowing us to report symbolized stack
traces of the point where missing source locations appear.

This patch completes the feature, having debugify handle origin stack
traces by symbolizing them when an associated bug is found and printing
them into the JSON report file as part of the bug entry. This patch also
updates the script that parses the JSON report and creates a
human-readable HTML report, adding an "Origin" entry to the table that
contains an expandable textbox containing the symbolized stack trace.

llvm#147008)

The Buildkite CI was unintentionally disabled for a few weeks. This
patch fixes the
CI jobs now that is has been re-enabled.

The use-case for `__is_same_uncvref` seems rather dubious, since not a
single use-cases needed the `remove_cvref_t` to be applied to both of
the arguments. Removing the alias makes it clearer what actually
happens, since we're not using an internal name anymore and it's clear
what the `remove_cvref_t` should apply to.

These changes were split off from llvm#146503.

This commit makes the output directories of libclc artefacts explicit.
It creates a variable for the final output directory -
LIBCLC_OUTPUT_LIBRARY_DIR - which has not changed. This allows future
changes to alter the output directory more simply, such as by pointing
it to somewhere inside clang's resource directory.

This commit also changes the output directory of each target's
intermediate builtins.*.bc files. They are now placed into each
respective libclc target's object directory, rather than the top-level
libclc binary directory. This should help keep the binary directory a
bit tidier.

This extension extends the subgroup block read and write functions
defined by `cl_intel_subgroups` (and, when supported,
`cl_intel_subgroups_char`, `cl_intel_subgroups_short`, and
`cl_intel_subgroups_long`) to support reading from and writing to
pointers to the `__local` memory address space in addition to pointers
to the `__global` memory address space.

It is already supported by the Intel OpenCL compiler.

Co-authored-by: Victor Mustya <[email protected]>

The prepare target was depending on the output of a custom command, but
wasn't the full path to that file. This tripped up CMake if the file was
removed as it didn't know how to rebuild that file.

Signed-off-by: Tikhomirova, Kseniya <[email protected]>

Signed-off-by: Tikhomirova, Kseniya <[email protected]>

Signed-off-by: Tikhomirova, Kseniya <[email protected]>

Signed-off-by: Tikhomirova, Kseniya <[email protected]>

Signed-off-by: Tikhomirova, Kseniya <[email protected]>

Signed-off-by: Tikhomirova, Kseniya <[email protected]>

Signed-off-by: Tikhomirova, Kseniya <[email protected]>